In the course of developing standardizations for communication technologies, requirement specifications are often provided. The requirement specifications are developed to support requirement testing of communication devices and to be used in such conformance test activities. The purpose of the requirement testing is to show that a communication device is compliant with the relevant communication standard this is shown by demonstrating fulfillment of the requirement specifications. Various requirement (or test) specifications commonly cover different aspects of the relevant standard such as, for example, compliance with control signaling aspects, correct data transfer, and performance within certain limits under certain conditions.
A common way to perform requirement testing of communication devices is to connect the communication device to a test tool (test system) and let the test system initiate different aspects of the communication device functionality. The test system then verifies that the communication device performs its tasks in compliance with the requirement specifications.
When terminal communication devices are to undergo requirement testing, a common prerequisite to enable test automation and to achieve repeatability of test results is that the terminal communication device comprises some specific test functions.
When testing certain aspects of communication standards, Mobile Originated (MO) data transfer is required. Mobile Originated data refers to data that is to be transmitted from a terminal communication device to a communication network, for example data transmitted in an uplink (UL) of a radio link in UTRA (UMTS Terrestrial Radio Access). To enable testing of such scenarios, test functions in the terminal communication device are needed to trigger and generate MO data transfer in the uplink (i.e. data transmission by the device under test).
To this end, the specific test functions in the terminal communication device may comprise a function adapted to loopback data. For example, such a function may be adapted to return data that was transmitted by the test system to the terminal communication device by transmitting the same data back to the test system.
This technique to loopback data is commonly used to test compliance in relation to different communication technologies, for example mobile communications technologies in relation to UTRA as specified in the 3GPP (3rd Generation Partnership Project) specification TS 34.109 “Terminal logical test interface; Special conformance testing functions”.
Examples of communication standards relevant for the purposes of embodiments of the present invention are GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunication Standard) and UMTS LTE (UMTS—Long Term Evolution). In the following the description of problems, which arise in connection with existing requirement testing methods and devices, and of the solutions thereof according to embodiments of the invention will be described with focus on UMTS LTE. It is emphasized, however, that the invention is by no ways limited to this communication standard, bur is equally applicable to requirement testing in relation to other communication as will be readily understood by the skilled person.
It is to be noted that all references to 3GPP specifications are to be understood as references to the versions of the specifications as published on the home page of 3GPP on May 6, 2008.
The 3GPP standard for UMTS LTE specifies how a terminal communication device should behave when it has data pending for transmission in the uplink. In order to verify such behavior, specific test functions to trigger and generate data for transmission in the uplink are required. In TS 34.109 referenced above, test functions have been defined for UTRA that perform loopback of data received from the test system in the downlink (DL) so that the data is returned in the uplink. In the test functions defined in TS 34.109 each data unit received in the downlink is directly returned in the uplink. Further, these test functions are based on that data units received in the downlink on a bi-directional radio bearer is directly forwarded to the uplink for transmission on the same radio bearer.
In order to be able to verify the terminal behavior for certain scenarios, there is a need to have means to control (e.g. from the test system) when the data sent in the downlink is to become available for transmission in the uplink in the terminal. Such a scenario might be a connection re-establishment after radio link failure when the terminal has data pending for transmission in the uplink (see e.g. R5-081618 (available from ftp://www.3gpp.org/tsg_ran/WG5_Test_ex-T1/TSGR5_39_KansasCity/Tdoc/R5-081618.zip), 3GPP RAN5 work plan for TS 36.523-1; R5-081618 is to be included in TS 36.523-1, “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Packet Core (EPC); User Equipment (UE) conformance specification; Part 1: Protocol conformance specification”).
Similarly, there is also a need to be able to verify terminal communication device behavior for certain mobility scenarios, for example for a handover between different radio access technologies (RATs) (see e.g. R5-081618 as specified above).
To be able to verify terminal behavior for such scenarios, the test system needs to be able to control the timing relation between certain events and actions in the test procedure.
The 3GPP specifications TS 23.401, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access” and TS 24.301, “Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3” define terminal behavior in respect of how the terminal should map Service Data Flows (SDF) to EPS-bearers to achieve necessary QoS (Quality of Service) based on a configured filtering mechanism (UL TFT—Uplink Traffic Flow Template). UL TFT is an example of packet filtering which is a more general term applicable also to other communication standards. The UL TFT may, for example, specify type(s) of service, port number(s), etc for different Service Data Flows. Similar functionality for how the uplink IP (Internet Protocol) packet flows are mapped to the correct bearer (e.g. the correct PDP (Packet Data Protocol) context) via UL TFT is also described in TS 23.060, “General Packet Radio Service (GPRS); Service description; Stage 2” and TS 24.008, “Mobile radio interface Layer 3 specification; Core network protocols; Stage 3”.
Test loops, such as those specified in TS 34.109 as reference above, do not provide loopback functionality required to verify correct UL TFT handling by the terminal device. Thus, means are needed to be able to test correct behavior of the terminal in respect of UL TFT functionality. There is a need to test handling of UL TFT within a same radio access technology. If for example new EPS-bearers or PDP-contexts are activated, or EPS-bearers or PDP-contexts are released or modified while the terminal remains within one and the same RAT. There is also a need to test handling of UL TFT when the terminal experiences a handover between radio access technologies. For example, after an E-UTRA to UTRA handover, EPS-bearers are replaced by PDP-contexts. Thus, correct handling of this situation in relation to UL TFT needs to be verified.
Therefore, there is a need for methods, arrangements and test systems that enables requirement testing of scenarios where the timing relation between certain events and actions in the test procedure needs to be controlled. There is also a need for methods, arrangements and test systems that enables requirement testing of scenarios where packet filtering is applied.